Document Actions
gvSIG-Desktop 1.10. User Manual
These notes supplement the documentation for the geoDB extension with regard to the driver for Oracle Spatial.
This driver allows access to any table from an installation of both Oracle Spatial and Oracle Locator (in both cases from version 9i onwards) which has a column that stores SDO-type geometries.
The driver only lists tables which have their geographic metadata in the USER_SDO_GEOM_METADATA view.
Given that each table’s metadata is available, the interface makes use of that data and automatically presents the column (or columns) of geometries. Likewise, ROWID, which is a unique descriptor for each row used internally by Oracle, is used and this ensures that identification is correct.
Two and three-dimensional data of the following types are supported:
- Point and multipoint
- Line and multiline
- Polygon and multipolygon
- Collection
At present, layers in LRS format (Linear Referencing System) are not supported.
Oracle has its own system for cataloguing coordinate and reference systems. Miguel Ángel Manso, on behalf of the Polytechnic University of Madrid, has provided a list of equivalent values for the Oracle system and the EPSG system and this is included in the driver as a DBF file.
Conversions from one coordinate system to another are carried out by gvSIG since its performance has proved to be superior.
The driver constantly performs geometric requests (in other words constantly calculates which geometries intersect with the current gvSIG view) and it is therefore essential that the database has a spatial index linked to the column in question.
If this index does not exist, an error window appears (figure 1) and the table or view cannot be added to the gvSIG view.
In addition, the driver needs to set a unique identifier for the records of the table or view, and this is not possible for certain types of views. If such a problem occurs, it will be detected by the driver and an error message will also appear (figure 2).
As a result, the view cannot be loaded to gvSIG from the database.
Figure 1. Warning regarding the lack of a spatial index
Figure 2. Warning regarding the fact that a ROWID could not be obtained
If you wish to export a layer to an Oracle database, you will also be asked if you wish to include the view’s current coordinate system in the table at the end of the process described in the manual. This may be useful in cases where we do not wish to include such information in the table for reasons of compatibility with other applications or information systems.
To work with two Oracle geometries (the most common case is an intersection), the two geometries must have the same coordinate system. Each geometry has an SRID field which can have the value NULL.
For instance, if we have a table with geometries in EPSG:4326 (Oracle code 8307) and another with geometries in EPSG:4230 (Oracle code 8223), it will not be possible to carry out SQL instructions to perform calculations directly between the geometries of one table and another. However, if these tables’ geometries do not have a coordinate system (i.e. SRID is NULL), then operations can be performed between the geometries of these tables, bearing in mind the errors involved in carrying out intersections between different coordinate systems.
When reading a table whose geometries have a coordinate system set at NULL, it is understood that the user will make sure that the geometries are appropriate for the current view, since no reprojection is possible (this may change with the new gvSIG extension for the advanced use of coordinate systems).
In short, not storing the coordinate system allows for a more flexible use of geometries.
